OCPBUGS-87343: Updating golang-github-openshift-oauth-proxy-container image to be consistent with ART for 5.0#367
Conversation
openshift-bot
force-pushed
the
art-consistency-openshift-5.0-golang-github-openshift-oauth-proxy
branch
from
0608c53 to
e65906a
Compare
|
Created by ART pipeline job run https://art-jenkins.apps.prod-stable-spoke1-dc-iad2.itup.redhat.com/job/aos-cd-builds/job/build%252Fsync-ci-images/201 |
WalkthroughThe PR upgrades build environment dependencies from Go 1.25 and OpenShift 4.22 to Go 1.26 and OpenShift 5.0. The CI operator configuration and Dockerfile base images are updated consistently to use the new builder and runtime images. ChangesBuild environment version upgrade
🎯 1 (Trivial) | ⏱️ ~3 minutes 🚥 Pre-merge checks | ✅ 15✅ Passed checks (15 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
openshift-bot
changed the title
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: openshift-bot The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
openshift-ci-robot
added
the
jira/valid-reference
|
@openshift-bot: This pull request references Jira Issue OCPBUGS-87343, which is valid. The bug has been moved to the POST state. 3 validation(s) were run on this bug
The bug has been updated to refer to the pull request using the external bug tracker. DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
openshift-ci-robot
added
the
jira/valid-bug
|
@openshift-bot: This pull request references Jira Issue OCPBUGS-87343, which is valid. 3 validation(s) were run on this bug
DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
Dockerfile (2)
1-9: 🛠️ Refactor suggestion | 🟠 Major | ⚡ Quick winAdd HEALTHCHECK directive.
The Dockerfile is missing a HEALTHCHECK directive, which is required by the container security guidelines to enable proper health monitoring.
💊 Suggested addition
Add a HEALTHCHECK before the ENTRYPOINT (adjust the endpoint/port based on oauth-proxy's actual health endpoint):
FROM registry.ci.openshift.org/ocp/5.0:base-rhel9 COPY --from=builder /go/src/github.com/openshift/oauth-proxy/oauth-proxy /usr/bin/oauth-proxy +HEALTHCHECK --interval=30s --timeout=3s --start-period=5s --retries=3 \ + CMD ["/usr/bin/oauth-proxy", "--version"] || exit 1 ENTRYPOINT ["/usr/bin/oauth-proxy"]Note: Adjust the healthcheck command to use an actual health endpoint if oauth-proxy provides one (e.g., HTTP /health or /ping).
As per coding guidelines: "HEALTHCHECK defined" from container security guidelines for
**/{Dockerfile,Containerfile}*.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@Dockerfile` around lines 1 - 9, The Dockerfile lacks a HEALTHCHECK directive required by the container security guidelines; add a HEALTHCHECK instruction placed before the ENTRYPOINT that exercises the oauth-proxy binary (referenced as /usr/bin/oauth-proxy and ENTRYPOINT ["/usr/bin/oauth-proxy"]) using an HTTP or TCP probe (e.g., curl/wget to /health or /ping on the appropriate port) and include sensible options (interval, timeout, start-period, retries); adjust the exact endpoint/port to the oauth-proxy health endpoint and ensure the command returns non-zero on failure so the container runtime can mark unhealthy.Source: Coding guidelines
1-9:⚠️ Potential issue | 🔴 Critical | ⚡ Quick winAdd USER directive to run as non-root.
The container lacks a USER directive and will run as root, violating the security guideline "USER non-root; never run as root." This is a critical security issue also flagged by Trivy (DS-0002).
🔒 Recommended fix
Add a non-root user before the ENTRYPOINT in the final stage:
FROM registry.ci.openshift.org/ocp/5.0:base-rhel9 COPY --from=builder /go/src/github.com/openshift/oauth-proxy/oauth-proxy /usr/bin/oauth-proxy +RUN useradd -r -u 1001 -g 0 oauth-proxy && \ + chown -R 1001:0 /usr/bin/oauth-proxy +USER 1001 ENTRYPOINT ["/usr/bin/oauth-proxy"]As per coding guidelines: "USER non-root; never run as root" from container security guidelines for
**/{Dockerfile,Containerfile}*.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@Dockerfile` around lines 1 - 9, The final image currently runs as root (ENTRYPOINT ["/usr/bin/oauth-proxy"]); create a non-root user (e.g., oauthproxy) in the final stage, chown or ensure /usr/bin/oauth-proxy is owned/executable by that user, and add a USER oauthproxy directive before ENTRYPOINT so the container does not run as root; reference the final stage binary path (/usr/bin/oauth-proxy) and the ENTRYPOINT to locate where to apply the changes.Sources: Coding guidelines, Linters/SAST tools
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@Dockerfile`:
- Line 3: The Dockerfile currently uses a broad COPY . . which pulls the entire
build context; replace that with explicit COPY instructions for only the
required files and directories (for example COPY go.mod go.sum ./ and COPY
<source-dir>/ ./<dest-dir>/ or COPY cmd/ pkg/ internal/ as appropriate) so you
avoid including secrets or unnecessary files in the image; update the
Dockerfile’s COPY statements to list the specific files/directories instead of
using COPY . ..
- Line 1: The Dockerfile currently pulls images from registry.ci.openshift.org
(the FROM line with the builder stage and the runtime base-rhel9 image), which
violates container security guidelines; update the FROM lines so the build-stage
uses an approved Red Hat builder image from catalog.redhat.com (replace the
current ocp/builder:rhel-9-golang-1.26-openshift-5.0 reference) and ensure the
runtime stage no longer uses base-rhel9/openshift-enterprise-base-rhel9 but
instead uses a UBI minimal or distroless runtime image from catalog.redhat.com
(for example a UBI minimal/distroless tag), keeping the existing builder stage
name (builder) and runtime stage names intact while switching the image
registry/type to catalog.redhat.com and a UBI-minimal or distroless image.
---
Outside diff comments:
In `@Dockerfile`:
- Around line 1-9: The Dockerfile lacks a HEALTHCHECK directive required by the
container security guidelines; add a HEALTHCHECK instruction placed before the
ENTRYPOINT that exercises the oauth-proxy binary (referenced as
/usr/bin/oauth-proxy and ENTRYPOINT ["/usr/bin/oauth-proxy"]) using an HTTP or
TCP probe (e.g., curl/wget to /health or /ping on the appropriate port) and
include sensible options (interval, timeout, start-period, retries); adjust the
exact endpoint/port to the oauth-proxy health endpoint and ensure the command
returns non-zero on failure so the container runtime can mark unhealthy.
- Around line 1-9: The final image currently runs as root (ENTRYPOINT
["/usr/bin/oauth-proxy"]); create a non-root user (e.g., oauthproxy) in the
final stage, chown or ensure /usr/bin/oauth-proxy is owned/executable by that
user, and add a USER oauthproxy directive before ENTRYPOINT so the container
does not run as root; reference the final stage binary path
(/usr/bin/oauth-proxy) and the ENTRYPOINT to locate where to apply the changes.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository: openshift/coderabbit/.coderabbit.yaml
Review profile: CHILL
Plan: Enterprise
Run ID: 5c9075ea-1736-47b2-a70f-a00d87136359
📒 Files selected for processing (2)
.ci-operator.yamlDockerfile
| @@ -1,8 +1,8 @@ | |||
| FROM registry.ci.openshift.org/ocp/builder:rhel-9-golang-1.25-openshift-4.22 AS builder | |||
| FROM registry.ci.openshift.org/ocp/builder:rhel-9-golang-1.26-openshift-5.0 AS builder | |||
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Verify the base image type and registry alignment with guidelines
echo "=== Checking if base-rhel9 is UBI minimal or distroless ==="
# Inspect the runtime base image metadata
skopeo inspect docker://registry.ci.openshift.org/ocp/5.0:base-rhel9 2>/dev/null | jq -r '.Labels | to_entries[] | select(.key | contains("name") or contains("summary") or contains("description")) | "\(.key): \(.value)"'
echo ""
echo "=== Checking builder image metadata ==="
skopeo inspect docker://registry.ci.openshift.org/ocp/builder:rhel-9-golang-1.26-openshift-5.0 2>/dev/null | jq -r '.Labels | to_entries[] | select(.key | contains("name") or contains("summary") or contains("description")) | "\(.key): \(.value)"'
echo ""
echo "=== Note: Coding guidelines specify catalog.redhat.com as source ==="
echo "Current images use: registry.ci.openshift.org"Repository: openshift/oauth-proxy
Length of output: 282
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "=== Tool availability ==="
command -v skopeo || echo "skopeo not found"
command -v jq || echo "jq not found"
echo
echo "=== Inspect runtime image (base-rhel9) ==="
set +e
skopeo inspect docker://registry.ci.openshift.org/ocp/5.0:base-rhel9
rc=$?
set -e
echo "exit_code=$rc"
echo
echo "=== Inspect builder image ==="
set +e
skopeo inspect docker://registry.ci.openshift.org/ocp/builder:rhel-9-golang-1.26-openshift-5.0
rc=$?
set -e
echo "exit_code=$rc"
echo
echo "=== Fallback: try to fetch manifest (network check) ==="
# Try to detect whether sandbox has outbound network; do not parse heavily.
set +e
curl -I --max-time 10 https://catalog.redhat.com/ 1>/dev/null 2>/dev/null
echo "curl_catalog_redhat_rc=$?"
curl -I --max-time 10 https://registry.ci.openshift.org/ 1>/dev/null 2>/dev/null
echo "curl_registry_ci_openshift_rc=$?"
set -eRepository: openshift/oauth-proxy
Length of output: 447
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "=== Locate Dockerfile(s) ==="
fd -a -t f 'Dockerfile' . || true
fd -a -t f 'Containerfile' . || true
echo
echo "=== Show Dockerfile(s) content (first ~200 lines each) ==="
for f in $(fd -a -t f 'Dockerfile' .); do
echo "----- $f -----"
sed -n '1,200p' "$f"
doneRepository: openshift/oauth-proxy
Length of output: 1375
🌐 Web query:
What is the purpose/content of the OpenShift CI image tag registry.ci.openshift.org/ocp/5.0:base-rhel9 (is it UBI minimal, minimal, distroless, or something else)?
💡 Result:
The image tag registry.ci.openshift.org/ocp/5.0:base-rhel9 (often referred to as base-rhel9) serves as a foundational Red Hat Enterprise Linux 9-based image used for building and running various OpenShift components within the OpenShift CI environment [1][2]. It is not a "distroless" image, nor is it strictly defined as "minimal" or "UBI minimal" by that specific naming convention. Instead, it is an OpenShift-specific base image—commonly known as openshift-enterprise-base-rhel9—maintained by the OpenShift Automated Release Team (ART) [3]. It is designed to be the consistent, enterprise-grade RHEL 9 base layer that downstream OpenShift component images use as their parent (via FROM instructions in Dockerfiles) to ensure consistency across the product [1][3][2]. Key points regarding its purpose and content: - Base Layer: It provides the required RHEL 9 user-space environment, shared libraries, and core configuration that OpenShift binaries require to run, replacing the older RHEL 8-based base images [1][3]. - Component Building: It is used as the starting point for creating various OpenShift service images (e.g., the installer image) [2]. - Standardized Maintenance: The image is managed to remain consistent with downstream product builds, ensuring that CI testing environment reflects the production environment customers will receive [3]. In the context of the OpenShift CI ecosystem, it is effectively the RHEL 9 iteration of the standard OpenShift base image [1]. While it shares common traits with minimal RHEL/UBI images, its specific identity in the ocp namespace is as the authorized, synchronized base for OpenShift product components [1][3].
Citations:
- 1: Dockerfile: add RHEL9 base image dockerfile images#124
- 2: https://github.com/openshift/installer/blob/master/images/installer/Dockerfile.ci
- 3: OCPBUGS-18860: Updating openshift-enterprise-base-rhel9 images to be consistent with ART images#149
🌐 Web query:
What is the purpose/content of the OpenShift CI builder image tag registry.ci.openshift.org/ocp/builder:rhel-9-golang-1.26-openshift-5.0?
💡 Result:
The image tag registry.ci.openshift.org/ocp/builder:rhel-9-golang-1.26-openshift-5.0 is a specialized container image used as a build environment within the OpenShift CI (Continuous Integration) infrastructure [1][2]. Its primary purpose is to provide a standardized, controlled toolchain for building OpenShift Container Platform (OCP) components [1]. By referencing this image in the FROM directive of a Dockerfile (or as a build_root_image in ci-operator configuration), developers ensure that their software is compiled using a specific, tested version of the Go programming language (in this case, Go 1.26) on a RHEL 9 base, consistent with the requirements of OpenShift version 5.0 [1][2]. The components of the tag indicate its specific configuration [1]: - rhel-9: Indicates the underlying Red Hat Enterprise Linux 9 operating system used in the image [1]. - golang-1.26: Specifies that the image includes Go version 1.26 [1]. - openshift-5.0: Identifies that this builder image is aligned with the OpenShift 5.0 release stream [1]. These images are managed by the OpenShift Architecture and Release Team (ART) [1]. When the required Go version or base OS for OpenShift changes, ART updates the central build configuration, and automation propagates these changes across the various component repositories by updating their build manifests [1]. Users are generally expected to use these officially provided builder images rather than custom ones to ensure compatibility with the OCP build environment and release processes [1][3].
Citations:
- 1: https://docs.ci.openshift.org/architecture/images/
- 2: https://docs.ci.openshift.org/architecture/ci-operator/
- 3: https://docs.ci.openshift.org/how-tos/use-registries-in-build-farm/
Base image registry/type don’t meet container security guidelines
Dockerfilepulls both build and runtime images fromregistry.ci.openshift.org(ocp/builder...andocp/5.0:base-rhel9), not fromcatalog.redhat.comas required by the guidelines.base-rhel9is an OpenShift enterprise RHEL9 base layer (“openshift-enterprise-base-rhel9”), not a UBI minimal or distroless image, so the runtime stage doesn’t satisfy the “UBI minimal or distroless” requirement.
🧰 Tools
🪛 Trivy (0.69.3)
[error] 1-1: Image user should not be 'root'
Specify at least 1 USER command in Dockerfile with non-root user as argument
Rule: DS-0002
(IaC/Dockerfile)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@Dockerfile` at line 1, The Dockerfile currently pulls images from
registry.ci.openshift.org (the FROM line with the builder stage and the runtime
base-rhel9 image), which violates container security guidelines; update the FROM
lines so the build-stage uses an approved Red Hat builder image from
catalog.redhat.com (replace the current
ocp/builder:rhel-9-golang-1.26-openshift-5.0 reference) and ensure the runtime
stage no longer uses base-rhel9/openshift-enterprise-base-rhel9 but instead uses
a UBI minimal or distroless runtime image from catalog.redhat.com (for example a
UBI minimal/distroless tag), keeping the existing builder stage name (builder)
and runtime stage names intact while switching the image registry/type to
catalog.redhat.com and a UBI-minimal or distroless image.
Source: Coding guidelines
| FROM registry.ci.openshift.org/ocp/builder:rhel-9-golang-1.25-openshift-4.22 AS builder | ||
| FROM registry.ci.openshift.org/ocp/builder:rhel-9-golang-1.26-openshift-5.0 AS builder | ||
| WORKDIR /go/src/github.com/openshift/oauth-proxy | ||
| COPY . . |
There was a problem hiding this comment.
🛠️ Refactor suggestion | 🟠 Major | ⚡ Quick win
Avoid copying entire context; specify needed files.
The guideline requires "COPY specific files, not entire context." Consider copying only the files needed for the build (e.g., go.mod, go.sum, source directories).
📋 Suggested refinement
-COPY . .
+COPY go.mod go.sum ./
+COPY cmd/ ./cmd/
+COPY pkg/ ./pkg/
+# Add other specific source directories as neededAs per coding guidelines: "COPY specific files, not entire context" from container security guidelines for **/{Dockerfile,Containerfile}*.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@Dockerfile` at line 3, The Dockerfile currently uses a broad COPY . . which
pulls the entire build context; replace that with explicit COPY instructions for
only the required files and directories (for example COPY go.mod go.sum ./ and
COPY <source-dir>/ ./<dest-dir>/ or COPY cmd/ pkg/ internal/ as appropriate) so
you avoid including secrets or unnecessary files in the image; update the
Dockerfile’s COPY statements to list the specific files/directories instead of
using COPY . ..
Source: Coding guidelines
|
@openshift-bot: all tests passed! Full PR test history. Your PR dashboard. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
|
ART wants to connect issue OCPBUGS-87630 to this PR, but found it is currently hooked up to ['OCPBUGS-87343']. Please consult with #forum-ocp-art if it is not clear what there is to do. |
openshift-bot
added
the
verified
3 participants
Updating golang-github-openshift-oauth-proxy-container image to be consistent with ART for 5.0
TLDR:
Product builds by ART can be configured for different base and builder images than corresponding CI
builds. This automated PR requests a change to CI configuration to align with ART's configuration;
please take steps to merge it quickly or contact ART to coordinate changes.
The configuration in the following ART component metadata is driving this alignment request:
golang-github-openshift-oauth-proxy.yml.
Detail:
This repository is out of sync with the downstream product builds for this component. The CI
configuration for at least one image differs from ART's expected product configuration. This should
be addressed to ensure that the component's CI testing accurate reflects what customers will
experience.
Most of these PRs are opened as an ART-driven proposal to migrate base image or builder(s) to a
different version, usually prior to GA. The intent is to effect changes in both configurations
simultaneously without breaking either CI or ART builds, so usually ART builds are configured to
consider CI as canonical and attempt to match CI config until the PR merges to align both. ART may
also configure changes in GA releases with CI remaining canonical for a brief grace period to enable
CI to succeed and the alignment PR to merge. In either case, ART configuration will be made
canonical at some point (typically at branch-cut before GA or release dev-cut after GA), so it is
important to align CI configuration as soon as possible.
PRs are also triggered when CI configuration changes without ART coordination, for instance to
change the number of builder images or to use a different golang version. These changes should be
coordinated with ART; whether ART configuration is canonical or not, preferably it would be updated
first to enable the changes to occur simultaneously in both CI and ART at the same time. This also
gives ART a chance to validate the intended changes first. For instance, ART compiles most
components with the Golang version being used by the control plane for a given OpenShift release.
Exceptions to this convention (i.e. you believe your component must be compiled with a Golang
version independent from the control plane) must be granted by the OpenShift staff engineers and
communicated to the ART team.
Roles & Responsibilities:
tests OR that necessary metadata changes are reported to the ART team
in
#forum-ocp-arton Slack. If necessary, the changes required by this pull request can beintroduced with a separate PR opened by the component team. Once the repository is aligned,
this PR will be closed automatically.
verify-depsis complaining. In that case, please opena new PR with the dependency issues addressed (and base images bumped). ART-9595 for reference.
any required labels to ensure the PR merges once tests are passing. In cases where ART config is
canonical, downstream builds are already being built with these changes, and merging this PR
only improves the fidelity of our CI. In cases where ART config is not canonical, this provides
a grace period for the component team to align their CI with ART's configuration before it becomes
canonical in product builds.
ART has been configured to reconcile your CI build root image (see https://docs.ci.openshift.org/docs/architecture/ci-operator/#build-root-image).
In order for your upstream .ci-operator.yaml configuration to be honored, you must set the following in your openshift/release ci-operator configuration file:
Change behavior of future PRs:
set up automatically. This means that such a PR would merge without human intervention (and awareness!) in the future.
To do so, open a PR to set the
auto_labelattribute in the image configuration. ExampleUPSTREAM: <carry>:. An example.If you have any questions about this pull request, please reach out in the
#forum-ocp-artSlack channel.